


Issue 3

Information to be validated in SMS and MMS messages that the test system receives from the terminal in interactivity tests This was debated a lot in the meeting. When the test system (i.e., the server in the network) gets an SMS or MMS, then how can it detect the choice that has been made by the user? How is this information formatted? And again to clarify .. We do not need to know the format of, e.g., the entire SMS, but only the format of information that indicates the choice. So if a terminal user selects to vote for choice A then how is this sent in the SMS - what in the SMS shows that the choice is A? Some concrete SMS and MMS content examples may help already to clarify this issue. But I would suppose that the BCAST standard should be more explicit on this as well. Note that this is not just an issue for a test system but also for any BCAST server implementer. So we wonder - how do THEY know which selection was made by a terminal? What are they parsing for in SMS and MMS content? Similarly how do terminal vendors approach this unclarity? 


Resolution 

According to the descriptions for format of the Interactivity Media Document in section 5.3.6.1.2 of the Service TS, in case of interactivity using sms the 'SMSTemplate' element provides a sub-element 'SelectChoice', which may have one more instances.

The 'SelectChoice' element consists of an attribute 'smsURI' and a sub-element 'ChoiceText' that are used in conjunction to describe a selection. In case of a voting application there may be multiple instances of the SelectChoice each with a unique value for the 'smsURI'. 

The client implementation is responsible for rendering information related to the voting application. Following is an extract of the Interactivity Media Document describing the setup of the SMSTemplate for an application with 3 selections.

<!--  SMS Template -->
	<xs:complexType name="SMSTemplateType">
		<xs:sequence>
			<xs:element name="Description" minOccurs="0" maxOccurs="unbounded">
				<xs:complexType>
					<xs:complexContent>
						<xs:extension base="LanguageString">
							<xs:attribute name="text" type="xs:string" use="optional"/>
						</xs:extension>
					</xs:complexContent>
				</xs:complexType>
			</xs:element>
			<xs:element name="SelectChoice" minOccurs="0" maxOccurs="unbounded">
				<xs:complexType>
					<xs:sequence>
						<xs:element name="ChoiceText" type="LanguageString" minOccurs="0" maxOccurs="unbounded"/>
					</xs:sequence>
					<xs:attribute name="smsURI" type="xs:sms:+417960001?body=$userid$%20$deviceid$%20Choice%20A" use="required"/>
				</xs:complexType>
			</xs:element>
			<xs:element name="SelectChoice" minOccurs="0" maxOccurs="unbounded">
				<xs:complexType>
					<xs:sequence>
						<xs:element name="ChoiceText" type="LanguageString" minOccurs="0" maxOccurs="unbounded"/>
					</xs:sequence>
					<xs:attribute name="smsURI" type="xs:sms:+417960002?body=$userid$%20$deviceid$%20Choice%20B" use="required"/>
				</xs:complexType>
			</xs:element>
			<xs:element name="SelectChoice" minOccurs="0" maxOccurs="unbounded">
				<xs:complexType>
					<xs:sequence>
						<xs:element name="ChoiceText" type="LanguageString" minOccurs="0" maxOccurs="unbounded"/>
					</xs:sequence>
					<xs:attribute name="smsURI" type="xs:sms:+417960003?body=$userid$%20$deviceid$%20Choice%20C" use="required"/>
				</xs:complexType>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="relativePreference" type="xs:unsignedInt" use="optional"/>
	</xs:complexType>


where the 
	Description element describes the event or query for which a following set of possible responses are presented for selection.
	ChoiceText element is used to provide a description text string associated to the selection.


------------------------------------------------------------------------------------------------------------------------------------------------------


Issue 1,2

Handling of Key Management Information (KMS) element
There have been some emails from Allysson on this reflector trying to clarify how this works. The main problem here was that there are multiple levels of encryption .. and guidance was needed as to which one should be used by the test suite and how to reflect this in KMS information element values in BCAST messages. 

Handling of SEK delivery via DRM or Smartcard 
Again - this has been brought up on this mailing list. How does SEK work in practice? How are the keys exchanged, e.g., on which and how many channels?. How much does the test suite need to control this activity, i.e., what exactly is the information that needs to be configured from the tests and is specific to a given terminal? 

Resolution

Both the above issues are related. KMS is required to address service/content protection using one of two possible mechanisms, Smart Card or DRM.

The description below first addresses KMS w.r.t. SmartCard and then DRM.

KMS using SmartCard.

The Service, Content, Purchase and Access fragments contain the element "ProtectionKeyID" that needs to be defined only when using SmartCard. As per descriptions provided in the SG-TS for a given service only one of the above fragments shall define it. 

As specified in the SG TS, ProtectionKeyID = Key Domain ID || SEK/PEK ID.

KeyDomainID is service provider specific. BCAST reused the definition from 3GPP MBMS spec: 

Key Domain ID = Mobile Country Code || Mobile Network Code, and is 3 bytes long.

MCC is 3 digits, and MNC 2 or 3 digits. Actually the first 5 or 6 digits of an IMSI contain MCC and MNC, and you can find list of MCC and MNC on Wikipedia.
For encoding check 3GPP 31.102 and 24.008. An example given in 31.102 is: using 246 for the MCC and 81 for the MNC, it becomes: '42' 'F6' '18'.

 MCC digit 2	 MCC digit 1	
 MNC digit 3	 MCC digit 3	
 MNC digit 2	 MNC digit 1	

SEK/PEK ID (or MSK ID in MBMS terminology) is 4 bytes long

with byte 0 and 1 containing the Key Group part
     byte 2 and 3 containing the Key Number part

The Key Number part value zero (0x0) is reserved for special use to denote the current SEK/PEK. 
The Key Group part value zero (0x0) is not allowed as it is reserved for future use. So for both, you usually start with 1, and then increment. The key group part of SEK/PEK ID is generated once per service/program, but the key number part may change over time. 

Example: when TV channel X is launched, the BSM assigns a value for the key group part, which can be any value that is >0 and that has not been assigned to other TV channels. When the BSM generates the first SEK, it sets the key number part to 1. After a month it generates the second SEK, with the same key group part as SEK1, but key number part 2; and so on.

The Key Domain ID and the MSK/PEK ID (only the key group part is relevant, as key number part may change) are put into SG to let client know which SEK/PEK (from the service provider the client is associated to) it should look for.

All IDs are used to identify which keys are to be used in association to what services, the actual key generation is the function of the encryption system which may or may not be incorporated into the BSM.

Regarding implementation of framework in a TTCN test suite, the KMS related information may be fixed as long as the corresponding encryption keys and the content is fixed. If the framework wishes to support the ability to change the sample content then it shall have to support run time definition of KMS related material.


KMS using DRM

According to the Service Guide TS 

description of baseCID element in the service fragment which states 

" For the DRM Profile, part of the Service or Program CID used to identify the corresponding asset within a OMA DRM 2.0 Rights Object. The Service or Program CID is obtained from the BaseCID as described in [BCAST10-ServContProt] section 5.5.1.
This element is only Mandatory to support for the network and terminal in case the DRM Profile is supported [BCAST10-ServContProt].
Note: for uniqueness of the baseCID see Appendix H. "


as per description in [BCAST10-ServContProt] section 5.4.3.

deviceRoID = E || deviceID || _S || stringtomakeitunique || "_I" || purchaseItemID || "_" || HEX(rekeying_period_number)
domainRoID = O || domainID || _S || stringtomakeitunique || "_I" || purchaseItemID || "_" || HEX(rekeying_period_number)
deviceID is the Unqiue Device Number (UDN) as discussed in [XBS DRM extensions-v1.0].
stringtomakeitunique Note that deviceRoID and domainRoID shall be globally unique. Note further that because of the specification of purchaseItemID in the OMA BCAST SG, the global uniqueness is already guaranteed and therefore, stringtomakeitunique shall be the empty string.
purchaseItemID is the GlobalPurchaseItemID associated with the purchase item and signaled in the Purchase Item Fragment of the SG(see Section ??5.8).
rekeying_period_number is a 7-bit counter that is used to differentiate between different ROs with the same purchase_item_id (defined in Section 7.2 of [XBS DRM extensions-v1.0])
I guess, by locating the purchaseItemID in the SG, the device can construct the RoID and therefore know which RO it should look for (SEK/PEK is conveyed in Rights Object in the DRM profile)


------------------------------------------------------------------------------------------------------------------------------------------------------


Issue 4

Authentication and acceptance of purchasing requests via the interactive channel Again here the problem of which authentication should be used for the test cases? What is the "default" scheme that everyone has to support (terminal and network alike)? Also what accounting scheme should be used in the tests? 

Resolution

According to the Service TS section 5.1.3 Authentication

Message Authentication for General Service Provisioning Messages
For the general Service Provisioning messages, message authentication SHALL be provided using HTTPS that SHALL be based on SSL 3.0 [SSL30] and TLS 1.0 [RFC 2246].
Subscriber Authentication for Smartcard Profile Service Provisioning Messages
Subscriber authentication for the Smartcard Profile SHALL be provided using HTTP digest as explained in [3GPP TS 33.246] or [3GPP2 X.S0022-A].

The specification is very clear on this there are no multiple options. As mentioned this applies to SmartCard profile I have no information on if authentication is needed in case of DRM profile and if needed, how it is realized.

